EnigmA Amiga Run 1997 July/EnigmA AMIGA RUN 20 (1997)(G.R. Edizioni)(IT)[!][issue 1997-07 & 08][EAR-CD IV].iso/lightwave/lwmlist/94.lightwave-08/000174_owner-lightwave-l _Thu Aug 4 16:10:59 1994.msg

Internet Message Format | 1994-09-05 | 6KB

Return-Path: <owner-lightwave-l>
Received: by netcom7.netcom.com (8.6.8.1/Netcom)     id PAA06422; Thu, 4 Aug 1994 15:16:10 -0700
Received: from goalkeeper.d2.com by netcom7.netcom.com (8.6.8.1/Netcom)     id PAA06338; Thu, 4 Aug 1994 15:15:57 -0700
Received: from d2.com by goalkeeper.d2.com via UUCP (931110.SGI/(930416.SGI)1.0-D2.COM-OUTERELAY)     for [e-mail] id AA14477; Thu, 4 Aug 94 15:11:58 -0700
Received: from arcadia.d2.com by omaha.d2.com via SMTP (920330.SGI/(921111.SGI)1.1-D2.COM-RELAY)     for [e-mail] id AA10852; Thu, 4 Aug 94 15:11:18 -0700
Received: by arcadia.d2.com (920330.SGI/(921111.SGI)1.1-D2.COM)     for @omaha.d2.com:[e-mail] id AA01822; Thu, 4 Aug 94 15:11:18 -0700
From: [e-mail] (Sean Cunningham)
Message-Id: <[e-mail]>
Subject: Re: Roto in Lightwave
To: [e-mail]
Date: Thu, 4 Aug 1994 15:11:18 -0700 (PDT)
In-Reply-To: <[e-mail]> from "Neil Richmond" at Aug 4, 94 11:03:51 am
X-Mailer: ELM [version 2.4 PL23beta2]
Content-Type: text
Content-Length: 4473
Sender: [e-mail]
Precedence: list
Reply-To: [e-mail]

:)
:) I received a note stating that rotoing using lightwaves image sequence is not
:) very accurate, that the images do not match the final frames, maybe some kind
:) of scaling of the image when it is loaded in. If this is so, then this is not

I haven't checked, but I don't think that the viewport scales to match the
aspect ratio of the resolution specified within the CAMERA pop-up.  I need
to check and see if the "safe" overlay changes as well.  I will most likely
compose for 2.2:1 or 2.35:1 (the current letterbox setting of 2:1 (I believe)
doesn't really match anything in the real world).  Without some kind of change
in the viewport, or at least in the "safe" overlay it will be very difficult
to compose shots.  I would need to make my own wireframe overlay and parent
it to the front of the camera, which would require much experimentation and
tweaking to get accurate results.

So this viewport thing isn't just a roto issue, but a compositional issue in
general.  I 'spose those that will never do anything beyond the default D2 or
D1 imageformats or those uninterested in integrating CG elements with live
plates need not worry about any of this...this may be why the issue has
never been raised (that I know of), as most LW work out there is rather
straightforward video stuff.

:) good. Especially, if you might be working in different formats. Can anyone
:) comment further on this? Also, having color for roto is not as critical as
:) having at least a 4-8 bit black and white. The disadvantage to color is that it
:) takes up a lot of memory and slows down any kind of preview. The need for higher
:) quality b&w, is that it makes for better roto, especially if the output is
:) going to be film.

When I roto in Prisms I almost always turn color off.  It dithers to 8bits
so looking at only luminance information makes fine details more visible.
Also, Prisms has a dessimation setting that allows you to quickly just
strip out ever n pixel on readin for doing quicky tests and faster feedback
when the display of finer details is not required.

:) We have the ability here to define a viewport to match the apect ratio of the
:) image to be rotoed.

An ideal solution would be either a pixel-aspect or aspect option right
next to your resolution requester.  So long as one is there, the other
can easily be calculated: PIXEL ASPECT = ASPECT / (XRES/YRES) ... or for
a practical example here's D1: .889 = 1.333 / (720 / 486).  I'm sure both
you, Allen and a majority of the listgroup know this, but the many aspect
ratios out there and pixel aspect ratios in particular were always very
confusing to me so it's a handy rule to have at your fingertips.

In addition to properly matching both the aspect of the viewport (which should
be as big as possible for the current Layout display resolution) to the
output resolution 1:1 the input roto image should be properly scaled to match
the viewport settings.  This sounds easy but there are alot of packages that
don't really take into account the pixel aspect ratio of your working display.
Say you need to roto a set of D1 frames with your output also D1.  You would
enter 720x486 with either a pixel aspect of .889 or an image aspect of 1.333.
What this should give you is a 1.333:1 viewport, and input D1 frames should
be scaled by .889 in X (giving you an image between 640x486 and 648x486,
depending on your desired precision) to match your viewport.  This makes sense
right, but you'd be surprised how many programs don't go all the way...it
should be a piece of cake to implement for square pixel displays like the SGI
and Mac...where it will get a bit more complicated is in the case of LW.
Most LW users are looking at a "standard" Amiga overscanned NTSC screen, which
has its own oddball pixel aspect ratio, so all of this needs to be accounted
for in both the viewport scaling as well as the scaling of input roto plates.
The reason I'm ranting on and on about this is because I've been thru the
roto ringer...I've stood there looking at a test tape trying to figure out
why my CG elements no longer line up with my BG plates when they matched
perfectly thru the interface of the software.  I've been a real nazi about
this at work, insisting that everything match-up 1:1, from low-res roto
plates to the final 2K film plates.

:) Later.
:)
:) neil
:)
:) " Give a skeptic an inch and he'll measure it. "
:) Neil F. Richmond         [e-mail]
:) Rhythm & Hues Inc.